FIG. 1 shows a typical data processing system 100 for processing data. Data processing system 100 includes one or more servers 102, 104, 106, and 108 and one or more clients 110, 112, 114, and 116, which communicate through a communication network 118, such as the Internet. The servers are connected to each other and to communication network 118 via a server intranet 120. And the clients are connected to each other and to communication network 118 via a client intranet 122. The servers can also be connected to each other via a backend tunnel 124.
Data processing system 100 performs communications in communication network 118 through packet switching, line switching, or another communication technology. In the data processing system, clients, such as client 112, issue data processing request messages 126 through communication network 118 to one of the servers, while one or more of the servers, such as server 104, process data or retrieve data responsive to the data processing request messages 126 and return response messages 128 through communication network 118 to the requesting clients.
Although not shown in FIG. 1, a load balancer is typically used to distribute the data processing request messages 126 from the clients to the respective servers depending on the processing loads of the servers, such that an even distribution of request messages among the servers is achieved. That is, the request messages normally identify the desired type of processing and the location of the data sets to be processed, however, the messages do not normally specify a particular server for carrying out the processing. In fact, it is conventionally irrelevant to the client which server carries out the data set processing, as long as, the correct type of answer or response is returned from the server and the correct type of data processing is carried out on the server side of the communication network.
For carrying out their respective functions, the clients and the servers are typically configured as shown in FIG. 2. Referring to FIG. 2, a client 202 is representative of each of the clients 110-116 of FIG. 1 and a server 204 is representative of each of the servers 102-108 of FIG. 1. In FIGS. 1 and 2, the same or similar reference numerals designate the same or similar parts. Client 202 comprises an interface 206 to a communication line 208 set up to communication network 118 (not shown in FIG. 2), a content data request program 210 for outputting data processing request messages 126, a client processor 212, a plurality of computer programs 214 and 216 (such as a browser 214 and a word processor 216), a display device 218, and a page setting program 220 for setting up a page format when sending and receiving data from server 204. Content data request program 210 and page setting program 220 can be part of a browser program.
Server 204 comprises a server processor 222, a request message reception program 224 for receiving messages from client 202, a content data provider program 226 for providing messages to client 202, at least one data processing program 228 (for example implemented as servlets using JAVA™ technology), an interface 230 for interfacing to the network, and a local data base 232 for storing a plurality of data sets, such as HTML pages. Request message reception program 224 and content data provider program 226 can be part of a web server program. Server 204 can also comprise a special service provider program 234, which provides special services that may not be provided by other servers. Server 204 retrieves or generates, in response to a data processing request message 126 from client 202, data that can be located in the local database 232 (static retrieval) or located elsewhere at another server. In the case that the data is located at another server, server 204 uses backend tunnel 124 to retrieve the data from the other server. Sun Microsystems, Sun, the Sun logo, and JAVA are trademarks or registered trademarks of Sun Microsystems, Inc., Palo Alto, Calif., in the United States and other countries.
Server 204 has an Application Program Interface (API) 236 for accessing an operating system and other devices. APIs provide an abstraction between a program and the kernel to provide portability of the program code. An API can also provide an interface between a high level language and lower level utilities and services that were written without consideration for the calling conventions supported by compiled languages. In this case, the API's main task may be the translation of parameter lists from one format to another and the interpretation of arguments in one or both directions. Thus, the API serves as a kind of interface unit to server processor 222 for processing the data in accordance with the type of processing requested in the client's message. Server processor 222, however, requires information about the type of processing requested and about the location of the data to be processed or to be retrieved on the server side.
FIGS. 3A and 3B depict flowcharts illustrating the steps of a conventional exchange of request messages 126 and response messages 128 between a client, such as client 112, and a server, such as server 104. FIG. 3A depicts the steps executed at the client, while FIG. 3B shows the steps executed at the server.
Referring to FIG. 3A, first, client 112 runs, for example, browser program 214 selected from the group of programs 214 and 216 on client processor 212. The client then determines the type of processing to be performed at the server (step 302). For example, if the user uses the browser program on the client to view a web page stored on the server, then the client will determine that the processing will be the retrieval of web page data. The dashed-line box associated with step 302, or with any other step described herein, indicates that the operation may involve the use of subprograms.
Then, client 112 determines the location of the input data to be processed (step 304). As will be described in more detail below, if communication network 118 is the Internet, then the location of input data to be processed may be indicated with a Universal Resource Locator (URL) specification.
Client 112 then sends data processing request message 126 to the server side of communication network 118 (step 306). Data processing request message 126 includes at least a first portion having an input data location reference that indicates the location of at least one input data to be processed at the server side of the data processing system 100. The server that receives request message 126 is conventionally determined by a load balancing function performed by a load balancer (not shown).
Referring to FIG. 3B, the server that was determined by the load balancer to receive the request message 126 then receives the request message 126 (step 308). For example, server 104 receives the request message 126. Server 104 then determines the location of the input data to be processed (step 310). The input data to be processed can be located on server 104 or at another location, such as on another server. Then, server 104 determines the type of processing to perform with respect to the input data, such as whether server 104 is to perform calculations using the data (step 312). In step 312, server 104 can also load a servlet 228 to perform processing on the data. Alternatively, server 104 can perform a predetermined type of processing, for example, if server 104 normally performs a particular type of processing on input data.
Server 104 then retrieves the input data from the location that was determined in step 310 (step 314). After the input data has been retrieved, server 104 processes the input data using the type of processing determined in step 312 (step 316). Then, server 104 generates a response message, such as response message 128, and sends the response message to client 112 (step 318). Response message 128 includes, for example, output data that was generated during the processing. Alternatively, response message 128 can indicate that a requested type of processing has been completed successfully.
Referring back to FIG. 3A, client 112 then receives response message 128 from server 104 (step 320). After having received the response message, client 112 then retrieves the processing results or requested data from response message 128 (step 322).
As described above with reference to step 310 of FIGS. 3B, servers are normally capable of determining the location of data that is to be processed when the input data is located, for example, in a memory or in a secondary storage. The conventional manner of doing this and a known problem associated therewith is depicted in FIGS. 4A and 4B.
Referring to FIG. 4A, FIG. 4A depicts a block diagram illustrating the conventional exchange of data processing request messages from a client and response messages from a server. As shown, two different types of data location references are required. A first type of data location references is used in the request messages to indicate the location of the input data to be processed. These data location references are called “in parameters.” A second type of data location references indicates a specified output data location, that is the location where the output data that results from the server's processing is to be outputted. These second type of data location references are called “out parameters.”
Thus, in parameters and out parameters specify the source and destination locations of the process data. More precisely, they conventionally specify the source and destination location addresses or location references where the data to be processed and the data that has been processed are stored. An example of a storage location identified by such a location reference or address is a memory address or a part of a memory array comprising a plurality of storage locations. Hereinafter, the storage location itself (e.g., the memory location) will be designated in capital letters, such as URLI, URLN, and URLO, while location references to the storage locations will be designated in small letters, such as urli, urln, and urlo.
FIG. 4A depicts the scenario in which request message 126 is sent from client 112 to server 104. As illustrated, request message 126 includes location references urli and urlo, which respectively identify the input URLI and output URLO locations for the input data and output data. Conventionally, request message 126 comprises the data location reference urli indicating the location URLI of at least one data set to be processed by server 104. Optionally, request message 126 further comprises the type of processing to be performed and an output location reference urlo identifying where the output data is to be stored.
In a typical example, request message 126 relates to a scenario in which a user at client 112 requests server 104 to fax a document located at a certain location URLI, which is indicated by the input location reference urli, to another location URLO, which is indicated by the output location reference urlo. In another example, the user may be using a word processing program and requests the server to translate a document located at a certain input data location URLI and to return the translation to the user at an output data location ULRO.
A resolver program at the server determines the input location URLI of the data from the input location reference urli in the request message, so that the server can fetch the data from the input location URLI. The resolver program is, for example, a web page hosting program. After performing the data processing on the input data, server 104 puts the output data into the output location URLO referenced by the output reference address urlo. As indicated in FIG. 4A, response message 128 may comprise an indication urlo of the output location URLO (an out parameter) where the output data is stored.
Further, in certain implementations, such as in Simple Object Access Protocol (SOAP) implementations, response message 128 may also have an attachment portion ATTACH. The attachment portion can be any type of attachment appended to the response message. Therefore, for example, the input data location URLI may be a data file located at server 104 and the data output location URLO may be a data file at server 104 or an attachment ATTACH attached to response message 128. As can be understood from FIG. 4A, it is necessary to specify input locations URLI in request messages, but optional to specify output locations URLO via the reference urlo. Depending on the type of desired processing, the client can also indicate a reference urlo for the output location URLO, or alternatively, the output reference urlo is generated by the server and is indicated to the client in response message 128. Accordingly, the place where the resultant data is output can be designated by out parameters, such as by URLs that can be resolved by a URL resolver, or by an attachment attached to response message 128.
Referring to FIG. 4B, FIG. 4B depicts a known problem associated with the conventional scenario shown in FIG. 4A. The problem arises when a request message includes an input location reference urliA that identifies an input location that is not a data file URLI, but is instead an attachment ATTACH to the request message itself. That is, the data to be processed is attached to the request message, which is a typical scenario in SOAP implementations.
While, in principle, the input location reference urliA will still serve the purpose of indicating the location of the input data to be processed, such an input location reference urliA is not understood by conventional URL resolvers. That is, a conventional URL resolver, as depicted in FIGS. 4A and 4B, expects to see in the input location reference urliA a URL that has a standard URL format, which indicates a typical memory location or the location of a data file. The location reference urlia, however, does not have this standard type of URL format and therefore the conventional URL resolver, when examining the input location reference urliA, is not able to detect the input location reference. Instead, the URL resolver typically ignores the input location reference urliA, because the content does not have the expected format for URL data location referencing. Therefore, the conventional URL resolver will not be able to identify the input storage location from the input location reference, when the input location reference identifies the request message itself or an attachment to the request message.
In SOAP implementations, the input location reference urliA serves as a kind of “envelope” for the attachment data, and a conventional URL resolver cannot identify this as a standard URL location reference. Thus, while SOAP attachments describe a way to reference attachments via URLs, these URLs cannot be resolved using conventional URL resolvers on servers since they do not reference a location accessible by a conventional protocol. Thus, if the request message carries input data to be processed at a server, the location of this data (as being a part of the request message itself) cannot be identified by the conventional server, and therefore the server cannot process the attached data.